home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 12005 < prev    next >
Encoding:
Text File  |  1996-08-05  |  3.1 KB  |  80 lines
  1. Newsgroups: comp.lang.c++,comp.lang.java
  2. Path: netcom.com!milod
  3. From: milod@netcom.com (John DiCamillo)
  4. Subject: Re: Java: What's the Big Deal?
  5. Message-ID: <milodDoF9JF.K32@netcom.com>
  6. Organization: NETCOM On-line Communication Services (408 261-4700 guest)
  7. References: <4i40ik$9dt@news4.digex.net> <milodDo5yDE.H8B@netcom.com> <4if9jc$rkm@druid.borland.com>
  8. Date: Sun, 17 Mar 1996 17:21:15 GMT
  9. Sender: milod@netcom16.netcom.com
  10.  
  11. pete@borland.com (Pete Becker) writes:
  12. >In article <milodDo5yDE.H8B@netcom.com>, milod@netcom.com says...
  13. >>ell@access1.digex.net (Ell) writes:
  14. >>>What is you can do in Java, you can't do as easily with a library in C++? 
  15. >>
  16. >>Write applets the run on the Web (duh! :-) Folklore has it
  17. >>that Sun couldn't even interest anyone in Oak until the
  18. >>applet idea came around.  Suddenly, everybody wants some.
  19.  
  20. >There's no reason you can't write a C++ compiler that generates a Java 
  21. >bytestream.
  22.  
  23. Are you claiming that arbitrary, correct (ANSI) C++ code can
  24. be compiled to the JVM and continue to work correctly?  Or are
  25. you claiming that a compiler can be written that will translate
  26. some limited subset of C++ into JVM?
  27.  
  28. And even if it is the former, given the limitations of the JVM,
  29. I suspect that the performance characteristics of the resulting
  30. program might be unrecognizable to the author.
  31.  
  32. >>Other merely practical advantages (for certain kinds of apps)
  33. >>include:
  34. >>
  35. >>1) Trade speed for safety (no pointer arithmetic + GC +
  36. >>   all casts dynamically checked + array bounds + ...)
  37. >>   This makes it a bit easier to program in than C++.
  38.  
  39. >Huh? Why can't you make these tradeoffs in C++? In fact, the problem is just 
  40. >the opposite: you can't make these tradeoffs in Java because it does not let 
  41. >you use pointers or handle your own memory management. This means you cannot 
  42. >decide that speed is more important than safety.
  43.  
  44. Right, which was exactly my point.  The tradeoff has already
  45. been made by the language in the right direction for certain
  46. kinds of apps. Thus, there is less work for the programmer,
  47. *assuming that you agree with the tradeoff*.
  48.  
  49. >>2) No header files => faster compilation
  50.  
  51. >Nonsense. Header files are simply text that gets included where you want it. If 
  52. >you write the same code without header files it will not magically compile 
  53. >faster.
  54.  
  55. It's not nonsense.  Cascaded #includes result in such a
  56. drastic inflation of the source text that it makes a measurable
  57. increase in compilation time.
  58.  
  59. >>3) Slightly simpler syntax (mostly due to the lack of
  60. >>   address operators, function pointers, and templates)
  61.  
  62. >Yup. The question, of course, is what this does to the expressive power of the 
  63. >language.
  64.  
  65. That's strange, I thought the question was "what can you do
  66. in Java that you can't do in C++", not the other way around.
  67. And, as I said, points 1 through 4 are practical advantages,
  68. not critical differences.
  69.  
  70. In any case, no one can answer your question until you define
  71. what you mean by "expressive power".
  72.  
  73.  
  74. -- 
  75.     ciao,
  76.     milo
  77. ================================================================
  78.     John DiCamillo                         Fiery the Angels Fell 
  79.     milod@netcom.com       Deep thunder rode around their shores
  80.